1. Technical Field
This disclosure relates generally to access control mechanisms in a distributed computing environment and, in particular, to techniques for evaluating context-based policies for authorization and entitlements processing.
2. Background of the Related Art
The eXtensible Access Control Markup Language, or XACML, is an Organization for the Advancement of Structured Information Standards (OASIS)-managed industry standard for managing access control policy. The industry standard is available from the OASIS web site. XACML provides an XML-based context-based security language for specifying access control policies. When used for access control, existing open standard formats such as XACML are focused around returning a single access decision, such as “permit” or “deny.” In contrast, “entitlements” involve the notion of returning a set of items for which access is allowed. Typically, entitlements are a set of control specifications (rendered through policies) that govern an identity's access to information, application and systems, where a user is one such identity. Support for entitlements is a common requirement to facilitate more efficient access control models.
In contextual security policy such as XACML, wherein an access control request is composed of a context containing attributes about the request itself and the relevant environment, entitlements often are provided by selecting from the policy a subset of these attributes to “index” and support. This approach, however, does not scale to large data sets where the data to be returned is defined in an external repository. Of course, a “brute-force” approach where every possible return value (from an external database) is examined by the authorization engine is not scalable.
More generally, the problem to be solved is how to determine which resources from a very large data set are authorized to have an action performed on them by a user. The criteria under which access should be granted is defined in a set of security policies; however, the resources that are being accessed are stored outside of the set of security policies, e.g., in an existing external repository such as a database or LDAP server.
Existing solutions to this problem (other than the brute force approach) either require pre-filtering the data before consulting a decision engine, or duplicating the set of possible resources into the security policy or a supplemental data store. In the pre-filtering approach, a two-stage process is implemented. The application first calls the database to build a candidate set of allowed values; then, for each value, the application calls an authorization engine using an authorization request to decide if the current user is allowed access. This approach has a number of limitations including that the security policy is duplicated or partially duplicated in both the application and the authorization engine. Because the query is often hard-coded into the application, any changes require development, test, production and Q/A cycle that is expensive and time-consuming. Moreover, in this approach the filtering responsibility shifts from the policy decision point to the application, and this creates a further burden on the application because it needs to make a series of individual authorization requests for each candidate (or a large access query for everything). In the data duplication approach, data is duplicated from the existing repository either into the security policy or a supplemental data store; then, the application calling the authorization engine uses an entitlement request to obtain the set of values. The limitations of this approach are that there is no longer a single canonical store of data, and the data duplication can require significant use of disk space and memory. Moreover, if the security policy approach is used, then changes to the set of possible values requires modifying the policy and loading it into the authorization engine, thus possibly implicating workflow and governance procedures.
It would be desirable to allow entitlements to be evaluated using a contextual security policy language such as XACML irrespective of whether resources being accessed are stored externally to the security policy.